home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000190_news@newsmaster….columbia.edu _Thu Oct 22 22:33:49 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA28664
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 22 Oct 1998 22:33:48 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id WAA07032
  7.     for kermit.misc@watsun; Thu, 22 Oct 1998 22:33:36 -0400 (EDT)
  8. Path: news.columbia.edu!panix!logbridge.uoregon.edu!xmission!news.cc.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Stop automatic resetting of terminal emulation?
  12. Message-ID: <wegLF5YIzlTM@cc.usu.edu>
  13. Date: 22 Oct 98 18:36:41 MDT
  14. References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu> <zr359kB7TU8S@cc.usu.edu> <70ofhk$e9d$1@apakabar.cc.columbia.edu>
  15. Organization: Utah State University
  16. Lines: 62
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:9386
  18.  
  19. In article <70ofhk$e9d$1@apakabar.cc.columbia.edu>, jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
  20. > In article <zr359kB7TU8S@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
  21. > :     Curious that you should bring up the topic because we had gone
  22. > : over it recently in the project. Let me indicate the two views on the matter.
  23. > :     First is the IETF view. It says when the remote host asks repeatedly
  24. > : for a terminal type the client is supposed to offer new kinds in each
  25. > : response, as a negotiation process. Thus if a remote host does not understand
  26. > : or accept one kind it asks again and the two sides run down their lists.
  27. > : Spelling counts for everything here, and no two machines seem to agree
  28. > : on spelling of terminal names. The RFCs do this haggle stuff.
  29. > :     The second is my view, which is the negotiation is stupid in the
  30. > : extreme. When the client responds with a terminal type that's it, there
  31. > : isn't more to the game. The remote host accepts or copes or rejects. The
  32. > : reason haggling is so stupid is there is a great deal more concerning
  33. > : terminal emulation than just the name/kind, and changing the name/kind
  34. > : upsets all other items associated with the session. Keyboard definitions,
  35. > : expectations by software at either end, and so on are most often tailored
  36. > : for specific terminal kinds, and here the IETF says it's fine to negotiate
  37. > : away that information without a word to the user. Amazing.
  38. > :     The fix, if we may use that term, is to force the terminal name
  39. > : in the SET TCP TERM command so only one kind is permitted to be offered,
  40. > : period.
  41. > :     Joe D.
  42. > 
  43. > Joe:
  44. > 
  45. > This case is not the same as the one that you and I talked about privately.
  46. > In your case, the terminal type name "VT320" is not recognized by the host,
  47. > a VMS system, but after the login occurs a terminal type query is sent
  48. > by the host which then recognizes the terminal type as a VT320.  This lack 
  49. > of host recognition of the Telnet Terminal Type negotiation is indeed 
  50. > caused by a failure of the host to have the same name for the terminal
  51. > as the emulator, but because it has an alternate identification method
  52. > things still work.
  53.     <omissions>
  54. >     Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
  55. >                  The Kermit Project * Columbia University
  56. >               612 West 115th St #716 * New York, NY * 10025
  57. >   http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org
  58. -----------
  59.     It is the very same thing we talked about. Please notice that I am
  60. not critisizing K95 et al, but I am blasting the IETF for letting things
  61. progress has they have. You nicely made my point by showing that some apps
  62. which expect a certain terminal type recognize things are not working and
  63. they don't work either. That is proper. Now the user has the opportunity
  64. to do something specific about the matter, rather than being deceived
  65. by Telnet Options. Some apps don't know and then we are in difficulties
  66. without realizing it.
  67.     Life would have been simpler if there had been both adherence to
  68. the list of terminal names and timely expansion of the same, and vendors
  69. who read before pressing keys. But like Unix itself, things got out of 
  70. control irreversibly.
  71.         Given the muddle my position remains: what the user selects is
  72. what he/she expects to receive. Telnet terminal kind is only one piece
  73. of a larger integrated sequence of actions and it cannot change its
  74. behavior willy nilly without bad consequences. 
  75.     What can be done? Well, there is a constructive alternative 
  76. available to us. One, enable both ends to deal with aliases of common
  77. terminal names. Two, allow different terminal kinds upon permission and
  78. control of the user. The first is readily accomplished in many cases, the
  79. second requires user interface modification.
  80.     Joe D.